TLDR

Pin the Zed extension deployment model as [SWR-IDE-ZED] across the specs and the shipwright-compliance skill — the WASM extension verifies the downloaded binary's SHA-256 digest in-extension while the cosign signature is checked at the release boundary — and land the shipwright-release-scope change-detection tool with its spec, schema, template, and fixtures.

Details

Zed deployment contract — [SWR-IDE-ZED]

• docs/specs/ide-extension-deployment.md: new [SWR-IDE-ZED] section. A Zed extension is WASM and cannot bundle a native binary; resolution order is user binary.path → cached download → verified github-release download (latest_github_release + download_file for the current platform → SHA-256 verified against SHA256SUMS → make_file_executable), then version-gated via LSP initialize. ~/.cargo/bin, bare-PATH, and worktree.which are forbidden as silent defaults. A download branch made unreachable behind a never-true guard (dead-download) is a FAIL. Publishing is a reviewed PR to zed-industries/extensions (submodule + extensions.toml + pnpm sort-extensions), WASM built reproducibly in CI, never committed.
• docs/specs/supply-chain-security.md: carve Zed out of cosign-signature-before-exec. The WASM sandbox has no cosign primitive, so the extension verifies the SHA-256 digest in-extension; the cosign signature over SHA256SUMS is verified at the release/CI boundary. Updated [SWR-SEC-CHECKSUM], the per-channel table row, and the Zed paragraph.
• shipwright-compliance skill (SKILL.md, reference/audit-checklist.md, reference/implement-release.md, reference/manifest-and-platforms.md): audit rules updated to match — digest-in-extension vs signature-at-boundary, worktree.which/~/.cargo/bin barred as silent defaults, dead-download as a FAIL, registry publishing mechanics.
• crates/shipwright-zed/src/lib.rs: module doc references SWR-IDE-ZED.
• .github/workflows/deploy-pages.yml: auto-deploy the website on push to main (paths docs/specs/**, website/**) instead of workflow_dispatch only, so the published specs stay current.

Release change-detection — shipwright-release-scope

• tools/shipwright-release-scope/: new Rust workspace member (adds the glob workspace dependency; Cargo.toml/Cargo.lock updated).
• docs/specs/release-change-detection.md (SWR-REL-CHANGES-*), schemas/release-scope.schema.json, templates/gh-actions/release-change-detection.yml, fixtures/release-scope/basilisk.json.
• fixtures/spec-coverage.json: coverage entry (SWR-SPEC-RELEASE-CHANGE-DETECTION) for the new spec.
• coverage-thresholds.json: 100% threshold for the new crate.

No breaking changes — spec/doc/skill updates plus additive tooling; all source version fields remain 0.0.0-dev.

How Do The Automated Tests Prove It Works?

• node --test tests/fixtures.test.mjs (7/7): each spec file has fixture coverage or a tracked ticket id now passes for docs/specs/release-change-detection.md (it was red — the spec existed with no coverage entry); tracked SWR ids do not use numeric suffixes passes for the new SWR-IDE-ZED and SWR-SPEC-RELEASE-CHANGE-DETECTION ids.
• make test: 100% line coverage across every crate including crates/shipwright-zed and tools/shipwright-release-scope; Dart resolver-vector tests and .NET tests pass.
• TypeScript matrix: @nimblesite/shipwright-core (55 tests), @nimblesite/shipwright-vscode (16), @nimblesite/shipwright-mcp (5) all pass.
• make lint: clippy (compiling the shipwright-zed doc-comment change), .NET warnings-as-errors (0), Dart analyze (no issues), and AJV manifest/schema validation all pass.